Due to the Internet Protocol version 4 (IPv4) network address space becoming exhausted, communications network operators are moving to deploy Internet Protocol version 6 (IPv6) networks. The Third Generation Partnership Project (3GPP) have defined standards for specifying possible migration techniques for operators when changing their mobile core networks from IPv4 to IPv6. However, as the majority of mobile core networks, and other communication networks such as the Internet, are still based on IPv4 addressing, the 3GPP have specified a NAT64 node for translating the UE traffic from IPv6 addresses to IPv4 addresses used by current communications networks and Internet services.
A UE may comprise or represent any device used for communications. Examples of user equipment that may be used in certain embodiments of the described access networks are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, net-books, computers, personal digital assistants and other wireless communication devices.
UEs attached to the mobile core network will use IPv6 addressing such that all the traffic to and from each UE is using IPv6 addresses. In order for the UE to access certain services in the Internet it will try to resolve the IPv6 address of the service via a DNS64 node. The UE sends the uniform resource locator (URL) of the service to the DNS64 node. The DNS64 node will try to resolve both IPv4 and IPv6 addresses for the given URL. If an IPv6 address is returned then the UE simply uses the native IPv6 connectivity for using the service. However, if only an IPv4 address is returned for the given URL, then the DNS64 node will synthesize an IPv6 address for the service. The synthesized IPv6 address will hold the 32 bit IPv4 address of the resolved service in the host part of the IPv6 address. The network part of the synthesized IPv6 address will hold the so-called prefix64 of a NAT64 node, which will perform the address family translation for the connection. The synthesized IPv6 address is returned to the UE by the DNS64 node as a reply to the URL resolve request. As a result, the UE will initiate communication to the service by using the synthesized IPv6 address.
All packets sent by the UE to a synthesized IPv6 address will be routed to the NAT64 node associated with the prefix64 of the IPv6 address. When the NAT64 node receives the first IPv6 packet destined to the IPv4 service it will create a translation state for this service. The translation state includes inner and outer 5-tuples, in which each 5-tuple holds the used upper layer protocol, protocol ports (or other info) and the destination and source addresses. The inner 5-tuple will hold IPv6 addresses used by the UE (source=UE address, destination=synthesized IPv6 address). The outer 5-tuple will have IPv4 addresses (source=IPv4 address from global address pool of NAT64, destination=IPv4 address from the host part of the synthesized IPv6 address). After a NAT64 translation state has been created it can be used to translate the incoming and outgoing packets.
3GPP mobile core networks have a Policy and Charging Control (PCC) architecture for providing a fair allocation of resources to all UEs attached to the communications network and to gather charging information about the resources used. The PCC architecture holds subscriber information of all the UEs in a Subscriber Policy Repository (SPR) node. The PCC architecture also includes a Policy and Charging Resource Function (PCRF), which is responsible for configuring UE specific quality of service (QoS) settings to an IP-Connectivity Access Network (IP-CAN) bearer session used for carrying the UE traffic. When UEs create new IP-CAN bearer sessions the PCRF node will acquire the subscription information from the SPR node via a Sp reference point and set policies matching the subscription information to use in a packet data network gateway (PDN GVV) via a Gx reference point. The PDN GW a Policy and Charging Enforcement Function (PCEF) node is responsible for controlling the QoS settings for the IP-CAN bearer session dedicated to the UE.
In a NAT64 node, the size of the translation state table or list for all UEs dictates the efficiency of the NAT64 node. This is because Internet services can many connections to download small pieces of data (e.g. Google® maps where each map tile is uses its own connection). When NAT64 node functionality is used in the 3GPP networks there is currently no control over how many translation states can be created in a NAT64 node for each UE. This means that some UEs might get access to more translation states states, and hence services, than others. However, if a static maximum limit were used per UE, then some services may be rendered unusable once this limit is reached. At the same time, some UEs might never require as many states as the maximum level would allow them to use, while others may use too many states overloading the NAT64 node or reducing the performance of other UEs.
A simple solution might be to deploy more NAT64 nodes, but this may still result in an unfair distribution of translation load amongst the NAT64 nodes. In a network with multiple NAT64 nodes, it is desirable that the translation load of the NAT64 nodes is evenly distributed. There is a need to dynamically monitor and control the NAT64 and DNS64 communication resource usage amongst UEs to provide a fair usage of communication resources.